=========================================================================
THE AMIGA TEXTURE-MAPPED GAMES FAQ V0.40
Steffen Haeuser haeuser@tick.informatik.uni-stuttgart.de
=========================================================================
History
V 0.1 First release
V 0.25 Added some more demos, layout is 80 charachters/line
V 0.26 Added History, layout is 75 characters/line
V 0.3 Added some additional info, added 3d-demo,
added Albas engine, added Wayne engine, added
source section.
V 0.35 Added A1200 smoothness values. Thanks to all the people
who sent me email, by the way... they help improving
the FAQ :))) Added some frame rates ...
V 0.4 Added short reviews of TextDemo57 and Alien Breed 3D
Table of contents
I. Introduction
1. What is Texturemapping ?
2. What are the problems of Texturemapping on the Amiga ?
3. How can they be solved ?
II. Short reviews of all demos/games/sources known to me
1. Demos
2. Game-Demos
3. Games
4. Sources
III. Rumours and other infos department
IV. Doing texturemapping with emulators
1. Hardware-Emulators
2. Software-Emulators
V. Algorithms
1. Terence Russells algorithms used in Wolf3D-2.lha
VI. The Amiga Texturemapping online conference
1. The invitation
2. Some hints for people who do not use IRC often
VII. What can YOU do to support this FAQ ?
I. Introduction
1. What is Texturemapping ?
Texturemapping is a method of wrapping bitmapgraphics around
vectors or 3D based graphics in common. For games, texturemapping
is mostly used doing very realistic Dungeons.
In contrary to a dungeon like in Dungeonmaster or Eye of the Beholder,
the player is not limited to some few directions, but he can turn
around in TRUE 360 degrees, like in real life. Often the graphics
is more realistic than the graphics of such block graphics games
and especially the opponents of the player are done very well
(using texturemapping and vector graphics ...)
Texturemapping is used for role playing games and for dungeon action
games (some of them able to handle more than one player at the same time).
The most famous such games are Castle Wolfenstein and DOOM. Castle
Wolfenstein is for PC and Mac, DOOM is for PC (and soon for Mac too).
There are probably more texturemapping action games than texturemapping
role playing games.
The original creators of DOOM did no port to the Amiga and won't do
so in the future. All the talk about "Amiga DOOM" is to do a similar
game on Amiga, not the original DOOM. Most people speak of "Wolfenstein
style" and "DOOM style" graphics engines to describe how GOOD the used
texturemapping in a game is. DOOM engines are superior to Wolfenstein
engines.
2. What are the problems of Texturemapping on the Amiga ?
Texturemapping needs to put single pixels to a screen, not only LINES
like in vector graphics. So you need both a fast CPU and a fast graphics
for doing texture mapping.
On PC (and on Mac) the color of each pixel is described by ONE BYTE...
this is the so-called CHUNKY PIXEL MODE. On Amiga, the color of each pixel
is described by EIGHT BYTES (for 256 colors). This is the so-called
BITPLANE GRAPHICS. Easy to understand, Chunky pixel is better for
texturemapping than bitplane graphics, as bitplane graphics only
has 12.5% of the speed of chunky graphics. Of course, if you take less
thean 256 colors the speed is better, and i was told, in this way you even
may get a better speed than doing chunky graphics.
Second thing, even if the 68040 is very fast, not everybody has got such
a thing(i have :)))) ). But on PC most gamers have got a 80486 (Which
probably is slower than the '040, but much faster than the '020). It is
probably not possible doing texturemapping with an 68000. In addition,
texturemapping should have 64 colors AT LEAST (maybe extra halfbrite
on ECS ...)
Third, a lot of companies let the Amiga alone (Boooooh... :((( ), and in
special they did not want to risk coding something DIFFICULT on Amiga.
And some coders simply are moronic DOS-lovers (greetings to ID Software
(they did DOOM) and to Richard Garriot of Origin at this place... i hope
they $"&$/&$"/$"/& (censored) !!!)
3. How can they be solved ?
A) Copper Chunky Modes
I told you before, that the Amiga is not capable of doing chunky modes.
That is not 100% the truth. There is a type of copper cheat (the copper
is one of the Amiga's graphics coprocessors), that in fact DOES chunky
modes. The problem with this graphics mode is, it can only handle a
resolution about 100x100 to 130x120 pixels (i do not know exactly, as i
am no specialist in coding texturemapping ...) Compared to PC Games with
320x200 texturemapping this may look ugly ... (but it should be mentioned,
games on PCs (at least on PCs that are not these absolute high-powered
ones...) often do not use full screen graphics, and so often too use such
resolutions. Copper chunky can't do 1x1 or 2x1 pixel resolution or
something like that (i do not know exactly what are the limits for that
Copper tricks... maybe an expert inc coding such things could tell me ?)
B) Chunky to Planar Conversion Routines
A Chunky to Planar Conversion Routine is a part of a texturemapping code,
that takes graphics in chunky (one Byte per pixel) as input, and puts it
as Bitplane Graphics on the Screen. Of course, this method needs much
CPU-power. For most demos/games, you should have at least a '030 to get
it smooth... and a lot of demos using this technique do not have FULL
texturemapping... that is, they for example have no stairs, and everything
on screen is on the same height level. Copper Chunky does this better, but
has a low resolution... of course a '040 with a Conversion Routine can
do fine things...
C) Using a graphics board
Graphics boards for the Amiga do not use Bitplane graphics, but, in fact,
Chunky graphics. The problem is, not many people have such boards in their
systems, in difference to the PC, where all graphics is based on such
boards. But some coders said, they maybe will do an additional "graphics
board version", that features the fast graphics chips with their chunky
graphics... there is even a texturemapping demo running on EGS (EGS is
a standard for Amiga graphics boards).
D) Demo-Groups do the Games
As those people who can do texturemapping best (on PC) often are
DOS-lovers, on Amiga a lot of people of the demo-scene and others, who
are not employed at software firms, began to code... and as software firms
want to SELL, they will probably sell the finished products, even if they
are Amiga-only... And of course there are firms DEDICATED to the Amiga,
like Team17 ... they are in this texturemapping business, too ...
II. Short reviews of all demos/games known to me
The short reviews are done in a specific format, mentioning Name, Author
Name (or name of one of the authors), Minimum System, Recommended System,
Engine style, How smooth the scrolling is and how good the pixelresolution
is. Then they are followed by a short description of the demo (of course i
could say more of the most, but there are a lot of demos reviewed...) Then
i list the E-Mail of the author (if available) and where on Aminet sites to
find the demo (if possible). I recommend using ftp.uni-paderborn.de or
src.doc.ic.ac.uk or another site with complete Aminet. Some smaller sites
only have got the latest uploads to Aminet. Wuarchive is a good choice,
too. And there is another good site called ftp.netnet.com or something
like that. You could look at ftp.luth.se, too.
Used abbreviations :
Minimum/Recommended System
All = All Amigas with 1 MB chip at least
020 = All Amigas with 68020 at least
AGA = All Amigas with AGA
030 = All Amigas with '030 at least
040 = All Amigas with '040 at least
060 = All Amigas with '060 at least (Joke! :))) )
FPU = All Amigas with FPU at least
EGS = All Amigas with EGS graphics boards
Engine style
Low = Engine worse than Wolfenstein,
Wolf = Wolfenstein-style engine
:) = A little Better than Wolfenstein, worse than DOOM
:):) = MUCH better than :), but not DOOM ...
DOOM = DOOM-style engine
Bey = Engine BEYOND DOOM
Smoothness
VSm = Graphics very Smooth
Smo = Graphics smooth
NSm = Graphics nearly smooth
Not = Not very smooth graphics
Pixel resolution
Cop = Probably copper chunky or some other copper cheat, maybe i am
wrong. In special CopL says low pixel resolution, CopM medium
and CopH says high resolution (but i think it is impossible
of doing a copper display with a pixel resolution you could call
HIGH). CopM probably is worse than Med. I used the CopL-CopM
abbreviations only to have SOME METHOD to differentiate
between different kinds of copper displays.
Low = Low resolution (probably something around 2x2 or worse...)
Med = Medium resolution (probably something around 2x1 or 1x2 ...)
High = High resolution (probably 1x1 ...)
Coded by
(P) = Single Person
(G) = Demo group
(PO) = listed person is one of those doing the thing... but there are
others...
(SF) = Software firm
All speed remarks are relative to my own system (hehehe...), an A4000/040
with 14 MB RAM and a Piccolo SD64 graphics board (not the standard Amiga,
isn't it ?) If you have an Amiga 1200 without accelator and did some tests
you may wish to mail your results to me ...
I have to remark too, that the comments are NOT objective... i like some
demos and games, and do not like others... no one should take it as an
insult, if i give his favourite demo a bad mark... it is only a try done
by me... if you think the other way round, tell me... maybe you can
convince me to change the FAQ as to one specific demo :))) I chose to be
STRICT in the remarks i had to do ... in order to show the differences
between the tested engines ... but of course i know how much work it is
even to do a texturemapping demo in LOW resolution with a TM-Engine that
suxx...
Sometimes i wrote something like Low/Wolf... then i did not want to say
Low, and not Wolf... again... everything very subjective ...
Ah... about that "recommended system" things... Just guesses...
Nearly all of the demos are on Aminet and for most of the demos
you will find in the FAQ in which directory. Most of the demos
also are (for the Germans reading this FAQ) available on the
Birdland BBS (number found at the end of this FAQ).
1. Demos
Only Demos with texturemapping parts that could be used in games are
mentioned... no textured spheres, cubes and such things... all things
mentioned in the chapter "Demos" will probably never get games ...
************************************************************************
Mindflow Stellar (G) AGA (4 MB RAM) AGA (4 MB RAM)
:) NSmo Med
One of the effects of this demo is a dungeon that looks nearly like the
dungeons of the game Ambermoon. The textures of the ceiling and floor
are MUCH better than in Ambermoon, but Ambermoon is smoother ...
Author : Stellar (One email of a Stellar-Member is
jsaarinen@kone.fipnet.fi, this is Nose/Stellar)
File : /pub/aminet/demo/aga/mindflow.lha
************************************************************************
Motion Bomb (G) AGA AGA
DOOM Not/NSm Med
One of the effects of this demo is a FULL texturemapped DOOM engine with
stairs and all. Bravo, Bomb !!! You should do a game out of this :)))
This demo did not run on my A4000/040, but i did get a patch from some-
one... i do not think this patch is on Aminet, though ... one last word
to the engine... there are stairs and all included, but the Speed i think
is not that sufficent for a game ... okay for a demo though...
Author : Gengis/Bomb
File : /pub/aminet/demo/par94/MotionDisk1.dms
/pub/aminet/demo/par94/MotionDisk2.dms
************************************************************************
Doomed Pearl (G) All All
Low VSm CopL
A demo where you can use the joystick to wander around... but i decided
not to do it to the Game-Demos, because the only intention to do this one
was, to prove it is possible of getting 50 fps on a plain A500. Someone
of Pearl tried to enhance the engine, but as this did not work, the demo
died. Talking about resolutions, there are copper chunky demos with
better resolution.
Author : Netrunner/Pearl (9308938m@lux.levels.unisa.edu.au)
File : /pub/aminet/demo/euro/Pearl.Doomed.lha
************************************************************************
Phobos Cydonia (G) All (???) All (???)
Low Smo CopL
One of the earlier approaches to Amiga texture mapping. It has no floor
textures and turning around does not look like it SHOULD... but asides
from that the speed is impressive. You can use your joystick to walk the
dungeon, in contrary to most not-game demos. The resolution is weak.
Author : ???
File : ???
************************************************************************
Fullmoon Fairlight (G) AGA AGA
Low NSm/Not Low
Even if Fullmoon is a very nice demo, the texturemapping part is not very
well done. The scrolling is not smooth, there are no floor and ceiling
textures and the resolution is low. The not texturemapping related parts
of the demo are nevertheless great !
Author : ???
File : ???
*************************************************************************
HOI-SAGAIII TEAM HOI (G) AGA AGA
Low NSm/Smo Low
The texturemapping part of the demo has no ceiling textures, and the floor
textures are not very well done. The speed is better than that of most
such "little hacks", but there are better texturemapping demos than this
one. Aside from this flaw, HOI-SAGA III is (looked upen on it as demo in
common) okay.
Author : Teamhoi@SterrBBS.nl (or was it TeamHoi@SterBBS.nl ???)
File : ???
*************************************************************************
Waynes Engine Wayne Mendoza ??? 040
DOOM ??? ???
This one will be DOOM-like graphics. But sadly Wayne_m said on irc he
would probably not do a game with it. I HOPE he changes his mind about
this :))) I do not know what the final name of the thing will be.
Author : wayne@msq.ruhr.de
File : Not yet available
*************************************************************************
2. Game-Demos
Game-Demos are Demos that are probably on their best way of getting games.
Some of them actually will get Games, some not ...
*************************************************************************
Warp_S O. Groth (PO) 020+HD AGA + Fast Ram
:):) Smo/Vsm Low/Med
Really a nice engine, the only DOOM style engine on Amiga with monsters
running around. This one will be a game 100%. Playable demo will be out
maybe February or March. The resolution and graphics are not the best at
the moment, but the next Demo out will (according to the beta i saw) be
much better. They got a new graphician, who is very good (i know this
one :))) ). Maybe the most promising demo of them all. It will get a
graphics board version, too, and an extra version that is '040-optimized
(higher resolution !!!) was promised sometimes... Was in the beginning
called Texmapp... The release version probably will be faster than the
demo. Uses not only 90 degree walls. Decompresses monster GFX in real
time. Just got a new beta from Oliver. Some bugfixes, you can shoot
(but there is no explosion graphics yet) and you have the option of
doing a speedup of the graphics. Maybe the engine is a bit faster
too...
Author : O.Groth@link-M.muc.de
File : /pub/aminet/gfx/misc/warp_s.lha
A1200 : Smoothness Smo
Frame : 19 fps on A4000/040
*************************************************************************
POOM Parallax (G) AGA 030+AGA
:):) Smo High
Maybe the most famous Amiga texturemapping demo. But it got very quiet
around it since October '94. Maybe they dropped it? Or maybe they will
bring out a complete game from one day to the other? There is a V0.3 on a
finnish BBS ... the coders did some talk about a "maybe" graphics
board version. POOM0.2 only has rectangular walls. The phone number of
the Finnish BBS is +358 18 161 763.
POOM0.2 is on Aminet ... As to V0.3 Beta, it is much smoother, you can
select a resolution from 32x32 up to 320x256 (the latter did not work
on my system, though...), you see the gun and there are some new
textures (a complete floor texture too...). As soon as you quit the
Beta, it crashes. The Beta does not run with 2 MB. Someone said,
the guys of Parallax would be working on something else at the moment,
so the next release of POOM would be some time away.
THE AUTHORS DO NOT WANT THE 0.3b BEING SPREAD. The real V0.3 will be
there somewhere in april.
Author : Jussi_Salmi@sonata.fipnet.fi
File : /pub/aminet/gfx/aga/poom_02.lha
A1200 : Smoothness Not (V0.2)
*************************************************************************
BSP John Fehr (P) All 040
DOOM Not Low/Med
This Demo reads an original DOOM-Wad-File and tries to interpret it. This
is SLOW, because WAD-Files were made for the PC, not for the Amiga ...
they are Intel-optimized... the WAD-interpreter BSP has no ceiling or
floor, but many features (because of the WAD ...) As it is No-Aga and
not very smooth, i do not think it is more interesting than for example
POOM or Warp_S. But it was probably VERY MUCH work to make this thing
reading .wad-Files ... and those multiple textures things probably cost
a lot of speed too... there are AGA versions in the archive too... they
too do not have floor and ceiling, but look better than the
ECS-version ... I was told, it seems, John Fehr now is doing something
further with his engine, but as to now i have no conformation from
himself (so, what about, this, John, if you read this FAQ ? :) )
Author : fehr@rpm2.aes.mb.doe.ca
File : /pub/aminet/gfx/misc/bsp1.0.lha
*************************************************************************
Tmapdemo C. Green (P) AGA AGA
??? NSm High
This demo comes with complete source... the author allowed doing a game
with his routine (he probably won't do himself ...) The engine is quite
cool, but very incomplete... just some blocks with Pics on the walls...
no collision check... but a floor...
Author : chrisg@commodore.COM (this email of course does not work ...)
File : /pub/aminet/gfx/aga/tmapdemo.lha
*************************************************************************
Tmapdemo S. Boberg (P) EGS EGS + EGS board
??? VSmo High
A Port of Chris Green's texturemapping engine to EGS... according to the
author a quick hack... probably won't get any further...
Author : ???
File : ???
*************************************************************************
Dentaku26 A.J.Amsel (PO) AGA/CD32 AGA/CD32
Wolf VSm CopL/CopM
Dentaku will be a Wolfenstein/DOOM-style game (probably with level editor
and serial device support). A.J.Amsel said to me, a demo will probably be
released in April 1995. An older demo (executable from September) is
available on ftp.luth.se. According to the mail information A.J.Amsel gave
me, he and the others formed now a software company which is called
Silltunna Software. They are two Coders (one of them A.J. Amsel), one
artist and Alistair Brimble doing the sound. The game uses a copper display
for its texture mapping routine. If you are a coder, an artist or a sound
specialist, you may wish to contact Mr. Amsel. Maybe you could join them
in there project (Mail to A.J.Amsel@exeter.ac.uk). A former Demo of
Dentaku was DentAWolf, but it has not much to do with Dentaku as
it is now. The ratings for DentAWolf are Low/Wolf,VSmo,Low.
The version of Dentaku found at ftp.luth.se is only optimized for
low end machines (but in my opinion it is good enough on high
end machines... maybe there is even room for an improvement of
the engine :))) And the engine does >20 fps on low end machines
too...) On high end machines you can even do 50 fps. The graphics
is of lower resolution as other games, but looks great anyway.
Author : A.J.Amsel@exeter.ac.uk
File : /pub/aminet/demo/aga/dentwolf.lha (DentAWolf...)
/pub/aminet/demo/aga/dentects.lha (Sept. Executable of Dentaku)
A1200 : Smoothness VSm
Frame : 50 fps on A4000/040
*************************************************************************
ChunkyMaze D. Bryson (P) AGA AGA
Wolf VSmo Med
A little dungeon with flickering torches and some pictures pinned to the
wall. It has no floor or ceiling textures and in some distance the
textures do not look nice. But there are worse tries. This project is
(even if there are better approaches) still alive, but as David Bryson
told me, the problem is the TIME. Anybody willing to help him, should
contact him per email. He did not do anything further by himself, but
Lee Metcalfe did some very nice graphics for the demo, and Paul Heams
coded a little further. David would like it, if someone with LOTS of time
picked this demo up. He would help this one with the source, of course.
I found a very similar demo on my harddisk (even the same textures...)
which is called wolf. I think it is an earlier or later version of
ChunkyMaze, but i do not have the docs.
Author : ceedb@cee.hw.ac.uk
File : /pub/aminet/gfx/aga/maze.lha
A1200 : Smoothness VSm
*************************************************************************
TextDemo5 J. Hendricks(P) 020 030
:) VSmo Med
In Fullscreen probably the fastest engine on Amiga (okay, POOM has floor
and ceiling textures and is not much slower...). Textdemo has Lightsources,
not-rectangular walls and the resolution and screen size can be
customized. The demo has OCS, ECS and AGA versions. It uses some very
tricky Chunky2Planar code (using even the blitter...). There is a
TextDemo6 in work, and as i was told this one will probably be one of the
best texturemapping demos on Amiga.
Author : john.hendrikx@grafix.xs4all.nl
File : /pub/aminet/gfx/misc/TextDemo5.lha
A1200 : Smoothness Not to VSm, according to screen size
*************************************************************************
TextDemo57 J. Hendricks(P) 020 030+Fast Ram
:):)/DOOM VSmo High
A long time, there was nothing new about Textdemo, but now it is on
Aminet !!! And it is probably the BEST texturemapping engine available
on Amiga, striking even Alien Breed 3D, POOM and Warp_S. I hope the
other coders won't take it this harsh and continue their projects
nevertheless :). On a fast '030 or a '040 it FLIES at near full screen.
I did it at 224x168 with 1x1 pixel resolution on my A4000/040 and
that looked ABSOLUT PHANTASTIC. John Hendrikx claimed he will do
a texturemapping engines for high end Amigas that will be AT LEAST
as good as DOOM, if not better...
Some features :
- Realtime movement (smoother on better systems, but not faster
than acceptable...)
- 128x128 textures (looks MUCH better ...)
- Multiple height walls :)))
- Floor textures (no ceiling textures yet...)
- "Bouncing movement" (I think the bouncing movement of TextDemo
looks better than that of DOOM !!!)
- Object-mapping-code for monsters included (but no animated
monsters implemented yet...)
- Textures take 24 Bit as original (so port to graphics board version
would be easy)
- something that looks like water (and the bouncing movement looks
like swimming :))) )
There are two teams doing games with this engine, John doing the engine
itself. The first team (the "Shade-Team") are five guys. They intend
to do a game with RPG elements that will be a mixture of DOOM, Dungeon
Master and Magic Carpet. The other Team ("Mystic tank") is doing a
two-person tank game.
Look forward to the next release (that shouldn't be a insult to the other
coders, but TextDemo is really GREAT ... did a long way from Textdemo5).
Maybe with that graphics board talk it would be nice if John did a
Cybergraphics version (if he reads this suggestion ... :) )
TextDemo57 is a sort of pre-release to TextDemo6. (Yeah! It is possible
on the Amiga! :))))))))))) )
Author: John.Hendrikx@grafix.xs4all.nl
File: wuarchive.wustl.edu/pub/aminet/gfx/misc/TextDemo57.lha
Frame: 8-26 fps according to screen and pixel resolution (according
to the fps display... sometimes it seems to me better than the
display says... at the low rates...)
*************************************************************************
Reality AGA K.Picone(PO) ??? ???
??? ???
This project is at present a Wolfenstein type engine that has up to now
not made it to a public release. I got some infos about it :
- Aimed for A1200 and CD 32
- Static and moving objects
- Solid and see through walls
- Floor and ceiling textures (will be done later)
- 1x1, 2x1, 1x2 and 2x2 pixel resolutions
- walls at any angle and of any length
- 64 colour GFX, maybe soon 128 or 256 colour GFX
- external back drop pictures
- simple multi height walls
- graphics board version (will be done later)
- ECS/OCS version (later, with some reduction)
- 320x256 1x2 in 7-8 fps on A1200 with 4 MB Fast
- 320x256 1x1 in 5-6 fps on A1200 with 4 MB Fast
There will probably be a demo release in 2-3 weeks ...
Author: ???
File : Not yet available
Frame : 8 fps on A1200 with Fast Ram
*************************************************************************
Albas Engine alba on irc (P) AGA ???
DOOM ??? ???
This one is intended to be a game in June. A DOOM style engine
with 1x1 and 2x2 pixel resolution. It will do 12 fps on 68030 50 MHz
with fullscreen and 1x1. In a small screensize and with 2x2 it
should be even playable on a plain A1200 system. But Fast Ram
is recommended. I did not see it up to now .... I do not have the
email of the Author. I do not know the final name of the game.
ALBA, PLEASE CONTACT ME !!!
Author: alba on irc
File : Not yet available
Frame : 12 fps on 50 MHz 68030
*************************************************************************
Alien Breed3D Team17 (G) AGA AGA+Fast Ram
DOOM NSm/Smo CopL
The famous Alien Breed 3D Demo is finally there. What do i have to say ?
It is a full Doom engine based on chunky copper. The demo is non playable,
but it seems to me, the game is nearly finished. I think the full game
should show up in 2 months or something like that. The demo does not
run on A4000 properly up to now, but it is said they will fix that
before the release. The graphics resolution is low, but as to nearly
finished games, it is probably the nearest to DOOM available on the
Amiga up to now. I think it will sell fine. :)))
*************************************************************************
Dogenstien3D J.D.Doig (P) AGA AGA
Low/Wolf VSmo Low
Texturemapping engine where you can see the gun while walking around. As
to the graphics, most other engines are better. I don't think this one is
still around. The first version was called Dog3D.
Author : jasond@cee.hw.ac.uk (it seems, that this is no longer valid)
File : /pub/aminet/gfx/misc (if it is still there ...)
A1200 : Smoothness VSm
*************************************************************************
3D-Demo J.Corigliano(P) 020+2MB+OS2.0 030+2MB+OS2.0
Low/Wolf Smo/VSmo Low
The first try of a completely OS-friendly texturemapping engine. Does
9 fps on my A4000/040. As to the Smoothness i HAD to say VSmo, but the
movement is very slow and you can see a bit of the screen refresh when
you turn around. But if this is the first try (the file is not very big),
maybe later versions will get much better. The main problem of the engine
probably is the speed... maybe an updated graphics would enhance it
too... up to now it does not have floor or ceiling textures and the
other "serious" engines are better... but remember, that is not a
public available demo version, but a frist executable...
Author : jcorig@strauss.udel.edu
File : Not yet publicly available ...
Frame : 9 fps
*************************************************************************
Wolf23_ish Chris Colman(P) AGA AGA
Low VSmo Low
A "first try" texturemapping demo. In the Readme the author writes he will
make this one better. It is NO copper chunky. But "as is" it is not very
good. An older version was wolf2.lha. Maybe another demo i found
somewhere (but lost the readme...) is an older or newer version of this
demo (it is quite similar). It is called wolf10. But maybe it is only a
similar demo from another author.
Author : cpc16@mp-s4.phy.cam.ac.uk
File : /pub/aminet/gfx/misc/wolf3.lha
(wolf10 is /pub/aminet/gfx/misc/wolf.lha)
*************************************************************************
Wolf3D T. Russell (P) All All
Low NSm Low
Another "first try" demo. I do not know anything about what got with it
after this release.
Author : russell@cpsc.ucalgary.ca
File : /pub/aminet/dev/src/Wolf3D-2.lha (with source)
*************************************************************************
Rot3D J. Freund (PO) FPU+1.5 MB FPU+1.5 MB
Wolf VSmo Med/High
One of the first, if not THE first texturemapping engine on Amiga
(now in its latest version). The wood textures of the demo look quite
well, as do the stone textures, but there are no floor or ceiling
textures and POOM, TextDemo5 and Warp_S are better. If no one picks this
one up, it will die. The authors said they would help a potential
"up-picker". It now seems it is dead.
Author : freund@cis.uab.edu
File : /pub/aminet/demo/euro/rot3d.lha
*************************************************************************
3. Games
*************************************************************************
TrickOrTreat D. Stuart (P) All All
Wolf Smo Low
Little texturemapping game, where two players try to shoot each other. The
graphics is not the best and there is no floor or ceiling texture, but it
is the first texture mapping action game on Amiga (yes, it is this one, NOT
Fears !!!) Even if the graphics is not comparable to Wolfenstein, the game
is a lot of FUN. The author wrote he was looking for some work in coding
the Amiga.
Author : ???
File : Amiga User International 11/94 (Coverdisk 45)
Or : Duncan Stuart,10, Bramble Close, The Beeches, Uppingham,
Rutland, LE15 9PH
*************************************************************************
Fears BOMB (G) AGA AGA
Low/Wolf VSmo Low/Med
This is a Wolfenstein clone for Amiga. The walls are better than nothing,
the floor textures nearly nothing, the monsters do slide instead of walk,
but it is a COMPLETE GAME. It is shareware. There is even sound while
playing. And it is really FAST.
Author : Gengis/Bomb
File : /pub/aminet/games/demo/fears.lha
A1200 : Smoothness Smo/NSm
*************************************************************************
Ambermoon Thalion (SF) All 030
:) VSmo Med
Ambermoon (do i have to explain this ?) is probably the best fantasy RPG on
Amiga. Using a cool texturemapping routine. Okay, the monsters of Ultima
Underworld on PC are better, but what do you want? This one is LoRes, 32
colors !!! One minute of silence for Thalion... may they rest in peace...
OR be back and do something like that in AGA ??? :))) But sure, that won't
happen... and the programmers for Ambermoon are now at Blue Byte, doing
Ambermoon's sequel Albion for PC only... BLUE BYTE SUXXXXXXXXXXXXXXX!!!
Ambermoon is a commercial game.
*************************************************************************
Legend of valour ??? All ???
Wolf(???) ??? Low (???)
Legend of Valour is a texturemapping fantasy RPG on Amiga. It is a
commercial game. I do not own it and only saw it once, so i can't say much
about this one. But it is not such BIG stuff like Ambermoon.
A1200 : Smoothness NSm (on the biggest screen)
*************************************************************************
A last remark for this chapter : The game DeathMask is no real
texturemapping. It is a block graphics game which scrolls around while you
turn 90 degrees. Better play Hired Guns ...
*************************************************************************
4. Sources
There are some demos available with sources. Additional you can find
the sources of Chunky2Planar routines on Aminet. My comments to these
will be rather short, as i am not familiar in coding texturemapping.
If you have comments to some of these sources, mail me ...
The format of the short reviews of the sources of course is different
to that of the demo reviews. I will download these sources too and
look them through. Maybe then there is something more i could say
about them.
*************************************************************************
c2p4.lha /pub/aminet/dev/src 31KB
Very fast c2p converter using cpu+blitter for the conversion. Needs
68020 at least.
*************************************************************************
chnky2plnr.lha /pub/aminet/dev/src 14KB
Various fast c2p conversion algorithms.
*************************************************************************
fastc2p.lha /pub/aminet/dev/src 25KB
Two fast c2p converters.
*************************************************************************
chunky.lha /pub/aminet/dev/src 54KB
Example of how to create a chunky copper display.
*************************************************************************
rot3dsrc.lha /pub/aminet/dev/src 184KB
Complete source of the above reviewed Rot3D texturemapping demo.
*************************************************************************
wolf3d-2.lha /pub/aminet/dev/src 56KB
Above reviewed texturemapping demo including source.
*************************************************************************
tmapdemo.lha /pub/aminet/gfx/aga 131KB
Above reviewed texturemapping demo including source.
*************************************************************************
flick-14.lha /pub/aminet/gfx/show 71KB
FLI/FLC viewer with source including a c2p routine.
*************************************************************************
III. Rumours and other infos department
1. Maybe DSA 2 (a texturemapping RPG with a really cool engine already
released on PC) will come to the Amiga, maybe not. I heard rumours about
a spring release (and my software dealer said there would be a good
chance for this one to be ported). I do not know if it is AGA, but i
think, if they do it, it will be AGA ...
2. There are rumours about ACID Software doing a clone.
3. Some guy on the net wrote there would be a clone from some polnish scene
member. He could not remember the name, though, and i do not know, if
this guy is reliable.
4. According to Amiga Report 233, AGE Entertainment is working at a
scrolling dungeon game. The game should come out as "Paranoia" and the
project began quite a time ago. According to the article in the
meanwhile the programmers think of the Amiga as a dead platform (the
programmers of Paranoia, not AGE Entertainment !!!), and even if they
wanted to finish the ECS version of the game, they wouldn't do the AGA
version and the CD 32 version that were planned at the beginning. Nor
would they do the planned sequels to the game.
5. Some time ago a group looked for coders for porting the game BOOM that
they were doing for the Atari Falcon to the PC and Amiga. I do not know,
if they found any Amiga programmers for doing the port. The game should
be in three parts, and one of the three parts would be a DOOM style
action game. I heard, it would be near finished (or finished...) for
PC ... (EMail : rrfriede@cip.informatik.uni-erlangen.de)
6. In the latest add from my software dealer there were announced some
games for Amiga AND PC that use texture mapping. These games are Body
Count, The castle of Dr. Radiak and the sequel of Elder Scrolls,
Daggerfall. I do not know, if this is an error or what (as i never
heard anything about it before ... and usually such things do not go
unnoticed...) And some of these releases were marked as CD and there
was NOTHING written about CD 32 ... this looks strange... but maybe at
least ONE is TRUE (if so, i hope it is Daggerfall :))) ).
7. It is said Renegade is doing a Wolf/DOOM clone.
IV. Doing Texturemapping with Emulators
1. Hardware-Emulators
Hardware-Emulators, that is ... putting INTEL-PROCESSORS in your poor
little Amiga. You want to do THIS ? Oh, than you are running PC games,
not Amiga ones... therefore i do not write ANYTHING about it in my FAQ.
Because this is nearly no emulation anymore... it is ... gaming on PC ...
there are quite well emulators of this style called "GoldenGate".
2. Software-Emulators
There are some software PC emulators, but for games like DOOM they are not
useful. They are slow and only emulate a 8088 or 80286. DOOM needs a
80386 AT LEAST to run. Maybe on PC Task 3.0 Wolfenstein will run. But the
speed (espescially the speed of the graphics) surely is a problem. Maybe
with a graphics board, but probably even this is too slow. So ... wait for
PC Emplant's CPU transcription mode (this one will not be included in the
first version of the emulation software, it will come as a free update
later ...)
Second ... Mac emulation with software... there are two emulators...
AMaxIV and Emplant... as i heard AMaxIV does not run on AGA ... and it uses
tricks to be able running with a 128KB ROM ... i doubt games running on
this one, but maybe i am wrong...
On Emplant (which i own myself) i tested four texturemapping games for Mac:
The demoversions of these games (which i tried...) are on ftp.hawaii.edu
in /pub/mac/info-mac/game/com. You will need StuffItExpander to decrunch
them.
Wolfenstein : Runs on my A4000/040 with reasonable speed (even if i do not
use the graphics board ... with PAL Hires AGA ...), but only with the
smallest screen. Not very well coded, as it is not very smooth on the
graphics board either... (okay, with 320x256 it is something near
smooth ...)
Sensory Overload : Wolfenstein Clone, but i do not like the graphics...
okay, the screen is bigger than most of these demos for Amiga... but the
graphics is not much better... i think worse... Sensory Overload does not
run well without a graphics board.
Pathways into Darkness : Wolfenstein clone from Bungie (Bungie1@aol.com),
i think the graphics is better than Wolfenstein, but Wolfenstein has a
background music and PID don't ... it is slow, but in LoRes playable
without graphics board... not much faster with graphics board, though ...
Marathon : The absolute Mega-Game ... rating, if we do it as with the Amiga
demos above : BEY !!! (Yes, this one is MUCH better than DOOM ...) If you
are doing EVERYTHING to play DOOM on Amiga, take this one, take the
smallest screen size, no music, select that the game only displays every
second line... and run it on at least a 4000/030. But do not show it to
your PC friends, they will LAUGH at you, if you do not own a graphics
board... (i did, before i got mine :((( ) On a graphics board, Marathon is
FANTASTIC, better speed than Amiga graphics demos, maybe even better than
DOOM on PC (remember, Marathon is 640x480 ...) I use a resolution of
probably 400x300 in Lores, and it is absolute smooth on the SD 64 ...
Marathon is the sequel to Pathways into Darkness.
One Last : It is rumoured, at 15th April, DOOM II will be released for
Mac... 68040 and PowerMac, to be exact...
V. Algorithms
In this chapter i will put algorithms or coding hints sent to me.
Please do not send code (this would be MUCH to specific for this
FAQ).
1. Terence Russells algorithms used in Wolf3D-2.lha
Basic structures and algorithms used to create the Amiga Wolf3D demo.
The techniques I have used do not involve ray-casting for the rendering
or BSP trees for hidden object removal. Instead my style of rendering
has more in common with flat-shaded polygon rendering used in many
older demos.
Sorry for the crappy organization. I'm a fourth year computer science
student and I haven't much time to do this properly.
The Maze and basic objects:
The maze is essentially two dimensional and if looked at from above it
would appear to be a grid whose squares are outlined with walls or are
bisected with doors.
Each square from above is 64 x 64 pixels in dimension. I use pixels as a
unit of measurement since in fact each point is represented by a pixel
column in a bitmap.
The use of the grid analogy is purely conceptual, however, since using a
grid structure would create some complications (which are described under
'collision detection' and 'door movement'). For purposes of discussion I
will refer to the X and Y axis' as being the east-west and north-south
axis' (respectively) of the grid from an above view. The Z axis will
refer to the axis that comes up out of the grid. (This runs contrary to
how I actually programmed the demo as the Y and Z axis are swapped).
Walls and doors are represented by the same basic unit: the block.
A 'block' is from a structural standpoint the canvas onto which wall and
door imagery is 'painted' or 'mapped'. Every wall and every door in
the maze is associated with a block. In fact a block may consist of
up to 4 walls that represent the 'north', 'west', 'south', and 'east'
faces of the block.
From a programming view a block consists of 256 points plus a center
point. The center point positions the block relative to the bottom-left
corner (0,0,0) of the maze. The remaining 256 are divided into 4 groups
of 64 points, each of which are associated with a particular block face.
All 256 points are relative to the block's center point. (Hence,
only one set of these points need be maintained for all blocks within a
maze). As can be imagined the end-points for each face overlap.
The walls points are given the following offset ranges:
SOUTH: (-32,-32,0) to (31,-32,0)
NORTH: (31,31,0) to (-32,31,0)
EAST: (31,-32,0) to (31,31,0)
WEST: (-32,31,0) to (-32,-32,0)
Notice that for each face the ranges are given in an order which implies
counter-clockwise as viewed from above the grid. This is important for
properly rendering the wall graphics and for backface culling, that is,
removing walls that are facing away from the observer/player.
Each wall/door has an associated 64 x 64 pixel bitmap. Each 1 pixel wide
column of the bitmap is represented by one of the points found along the
wall/block face. Hence point 0 of the south wall of a block may represent
the 0th column of a 'stone wall' bitmap. From the programmer's view I use
the wall point's ordinal value (it's relative position) to offset/index
into the bitmap image.
Previously I mentioned that blocks are used for BOTH walls and doors.
The attentive reader may have noticed that the offsets for the walls
would create doors that are not located in the center of a block. Since
my aim was to create a near Id wolf-clone I had to specify extra offsets
just for the doors. These new offsets simply have either the X or Y
component zeroed depending on which direction the door is to lie along.
This allows the doors to appear in the center of a block. This also makes
it easy to have sliding doors since all I really need to do is move the
associated block's center point in the direction the door opens. The door
then slides 'into' an adjacent wall block which takes care of hiding the
door. (This is explained later in the next section).
RENDERING - this is just a quick and dirty algorithm
Translate the block centers by an amount equal to the players relative
maze position. Now rotate these centers using the players attitude or
angle of direction, also relative to the 0,0,0 point of the maze.
Next rotate the 256 wall points using the same players direction angle.
For each block center, translate a copy of the 256 wall points to the
block center such that the block center is in the middle of the points.
Now that we have a list of block points that are relative to the player's
position we want to render the blocks. To determine what blocks are
visible I simply sort them by there Y value, (which is now relative to
the player's position). I used this method since at the time I did not
know of the BSP tree method for determining visible polygons.
Once we have a list of sorted blocks, we can immediately discard the
blocks that fall behind the viewer. From this point we render each block
until the player's view is completely filled with graphics.
Since I don't want to draw all of the blocks that are in front of the user,
(just the ones that fill up the view), I use a pre-render loop which
determines what portions of walls/doors are visible.
To determine what is visible I use the sorted list of blocks and an array
called the xBuffer. This buffer is one dimensional and has an entry for
every vertical column of the user's game display.
The algorithm involves a lot of simple parts that when put together create
a fairly complex program. Hence I will attempt explain it using two similar
explanations.
EXPLANATION 1:
I use the following algorithm:
clear the xBuffer
while xBuffer is not full do
get the block closest to the player
for each face of the current block do
if current face is invisible then
skip face
else "current face is visible"
for each of the current face's 64 points do
perform a perspective calculation on the point to
get a screen X1,Y1 point.
duplicate X1 into X2
mirror Y1 across the center of the display to get Y2
the line (X1,Y1)-(X2,Y2) forms a column of screen points
onto which a column slice of the wall/door bitmap will
be mapped/scaled.
if X1 lies with in the range of the xBuffer
(usually 0-319 for a full screen) then
check xBuffer[X1].height to see if a column
hasn't already been written there.
IF height of current line > xBuffer[X1].height THEN
xBuffer[X1] = current column and it's associated
bitmap imagery.
else
discard this column as being invisible.
endif
"If all I did was insert just the columns into the
xBuffer there would be gaps in-between the columns
do to the perspective transformation, hence
I need a little loop that makes a copy of the
current column back to the previous column of the
same wall."
end-if
end-for
end-while
For example suppose my maze viewing area is 320 pixels across the screen.
Then the xBuffer has 320 elements. Each element is a structure that
records: the half-height of the wall/door from the horizon or the equator
of the viewing area; the bitmap identifier; the pixel column offset into
the bitmap
Now using the xBuffer I have a routine take each element and read a column
of pixels from a bitmap and then stretch and clip the bitmap into the
hidden rendering buffer.
EXPLANATION 2:
while not done do
check closest wall/door's extents
(i.e. the starting and ending X locations as project on the view)
if the extents are outside the viewing area then
discard the wall/door
else
for each of the 64 points/columns of the wall/door
determine where the column is relative to the view area
if the column lies in the view area then
check the corresponding xBuffer element to see if
something hasn't already been written there
if empty then
write the columns height and bitmap column offset
and bitmap identifier to the xBuffer.
else
if current column's height is greater then
write it
else
this part of the wall lies behind some other wall
end
end
end
end
end
end
Starting with the closest block I check each face to determine if it is
visible. Since the faces of the blocks are at angles of 90 and 180 degrees
from each other, at most 2 faces will be visible at any one time.
Once I determine a visible face I use the associated 64 points for that
face to determine visible columns. To each point I add to the Z component
an amount equal to have the height of a wall. Then I run the point
through a simple perspective calculation and I now have a somewhat correct
position for projecting the point onto the player's view.
I next create a duplicate of the point and mirror it across the middle
of the player's view. This gives me two points that represent a line or
column of the wall's bitmap. Since each point of a face is uniquely
associated with a column of pixels in a wall bitmap I can perform some
sort of 'texture' mapping now. Only one thing remains, and that is to
determine the next columns position. Since as you get closer to a wall
the 64 points will be spread out over a greater viewing area, gaps will
start to appear between the columns. These gaps are eliminated by copying
a column up to the next column.
Collision Detection:
Some authors have suggested using a static grid to perform collision
detection with walls. Generally this works very nicely, however, in the
case of Id's Wolf3D there is a slight problem. Id's game supports moving
walls (in other words the secret passage-ways). To perform collision
detection on these moving walls while using the static grid meant that
I would need to either create special case for checking when a wall was
moving, or would have to create a special kind of block: i.e. a moving
wall block. At the time I decided this was unsatisfactory so instead of
using a grid I decided to use the block's center point and a bounding box
around the player. Using this method, collision detection involves
checking each block center to see if it lies within the players bounding
box. This allows me to move blocks at will without worrying about special
cases and is generally pretty quick.
There are many more points to the algorithms I have used, and if you
are interested in understanding them and want to learn a maze rendering
technique that does not involves ray-casting then send some email.
Terence Russell
russell@cpsc.ucalgary.ca
VI. The Amiga Texturemapping online conference
[This information is dated. More recent information will be printed when
it is available. -Jason]
1. The invitation
At 7th February (Tuesday) at 22.00 MESZ (16.00 EST or 15.00 Central US
Daylight Saving Time) there will be a online conference on IRC about Amiga
Texturemapping. The conference will be on a channel name #amitmap.
Everyone who is interested in Amiga Texturemapping is invited. The talk
will be about the future of Amiga Texturemapping and as some programmers
already announced they would be there probably some coding themes. Maybe
there will be the possibility to find more people for an own project.
2. Some hints for people who do not use IRC often
IRC is the online chat system of the internet. Try out the command irc on
your site. If this does not work, contact your system administrator and try
to convince him to install an irc server :))).
As you entered irc, you specify your nick name (the name under which you
will be known), with /nick Nick-Name. An alternative is starting irc with
irc Nick-Name. To enter a channel (a channel is a place for people
discussing a specific theme to meet), you type /join channelname.
Each channelname starts with a #.
To send someone a private message (that other can't read) you type /msg
Nick-Name "...", where Nick-Name is the Nick-Name of the user, to whom you
will send the message. To send a message to all users in this channel,
simply type what you want to say. Usually you should write it in the
following way : Name of the user for whom this message is
primarily : Text.
/who * lists all users currently on this channel.
/list * counts the users on this channel.
With /quit you quit irc.
That are only the basics for irc, but with that knowledge you can be with
us at the conference :))). Irc also has a help-system installed,
by the way.
VII. What can YOU do to support this FAQ ?
1. Support Amiga
2. Write texturemapping demos/games on Amiga :)))
3. Buy Amiga texturemapping games, if they come to a release
4. If you know of any texturemapping game/demo not mentioned in this FAQ
(dungeon-related, no texturemapped cubes and spheres),
or if you have information relevant for me, mail to
- haeuser@minnie.informatik.uni-stuttgart.de
OR
- call Germany 07021/861920 or 862428 or 862429 (Birdland BBS,
i am Magic SN on this BBS ...)
OR
- Phone Germany 07021/51787 and ask for Steffen
OR
- go in irc and look for MagicSN (that's me :))) )
OR
- write a letter to Steffen P. Haeuser, Limburgstr.127,
73265 Dettingen/Teck,Germany
OR
- Do whatever you want ... :)
5. Do the same, if you want to send me critics or beta-releases of demos
to test them :)))))))))))))))) (at least i tried it... maybe someone
would be in FACT that nice :))) )
My internet-account is able to handle BIG UUEncoded mail... :))))))))
6. Spread this FAQ on all nets and BBS's.
7. If you are a coder, and you have a lack of time to code, or you have
a serious problem in coding texture mapping, maybe you find some
interesting EMail-Adresses all over this FAQ ...
8. Send me texturemapping algorithms you see no need anymore in
keeping them private (for this new chapter V)
That's it... as soon, as i hear news about some of the mentioned demos
(or of some new ones ...) i will do a later version of this FAQ. It will be
found in comp.sys.amiga.games at least... maybe soon there will be a later
version of Warp_S or POOM or TextDemo or DentAWolf or... or ...
ciao,
Steffen Haeuser
OR MagicSN (in irc)
OR haeuser@tick.informatik.uni-stuttgart.de (E-Mail, talk ...)
converted with guide2html by Kochtopf